1. Field of the Invention
Generally, this application relates to data decoding. More specifically, this application relates to methods and systems for the efficient handling of escape code during the decoding of N-tuple variable length codes.
2. Description of the Related Art
Advanced audio coding (“AAC”) and MPEG, layer 3 (MP3), methods are used in various applications implementing audio codecs, including wireless, CATV, digital broadcast and Internet arenas. The AAC standard specification is ISO/IEC 13818-7, and the MP3 standard specification is ISO/IEC 11172-3, layer III, both of which are fully incorporated herein by reference. AAC generally provides higher efficiency audio encoding than MP3 encoding. However, both AAC and MP3 decoder technologies rely on Huffman coding and decoding of symbols using variable length fields. In the MP3 and AAC specifications, each variable length bit field can represent, for example, values for 2 or 4 consecutive symbols. For convenience, such groups of symbols will be referred to generally as an N-tuple symbol, where the “N” signifies the number of symbols encoded.
Generally, Huffman coding and decoding is based on a statistical algorithm, which means that the probability of occurrence of a symbol has a direct bearing on the length of its code representation. The higher probable the occurrence of a symbol, the shorter its bit-size representation. Huffman lookup tables are used during decoding to reconcile the variable length codes to the encoded symbols.
Huffman tables used during decoding can require escape handling for some symbols. Escape handling may be required when the coded symbol set is big. For example, to achieve efficient coding for more frequently used symbols, it is a typical practice to put some less frequently used symbols in a group, and then to use one special Huffman code to represent this group. Inside the group, each symbol is assigned with a distinct value in addition to the special Huffman code. This practice is known as escape handling. The value corresponding to the special Huffman code is called the escape value or escape threshold. Usually, media standards use different escape values; for example, AAC uses a value of 16, while MP3 uses a value of 15. Furthermore, the number of additional bits assigned to escape symbols varies from standard to standard.
There are generally two typical implementations of escape handling during decoding using Huffman tables. The first typical implementation resolves the symbols one by one to determine whether escape handling is required, with escape intervention provided by the processor or controller in conjunction with the associated escape software. The second typical implementation also resolves the symbols one by one; however the escape handling logic is hard-wired for the specific standard. Thus, the detection of escape symbols depends on a comparison of all N-tuple values against the escape value, or escape threshold, defined by a particular standard. Such conventional implementations result in poor computing performance because of this symbol-by-symbol comparison of each value in the N-tuple symbol.
FIG. 1 illustrates the typical Huffman decoding of an AAC or MP3 bit stream, which uses the detection of escape symbols. This typical detection procedure depends on the comparison of all of the values of an N-tuple symbol against the media-standard-dependent escape value, or escape threshold. As shown in FIG. 1, steps 110-130 start the N-tuple symbol decode process by initialing the decoder to read the variable length code (VLC) and performing variable length decoding (VLD) lookup(s). At steps 140, the decoder has returned the N values of the N-tuple fields. The decoder next compares, at steps 150, each of the N output values against the media-standard-dependent escape threshold(s) to determine whether any of the N values is indicative of an escape symbol. Step 160 decides whether any of the N output values indicates an escape symbol. If none of the N values is an indicator of an escape symbol, then this N-tuple symbol is not an escape condition and decoding of the N-tuple is complete (step 180). Otherwise, the N-tuple symbol is an escape code and requires further handling (step 170), prior to completion of decoding for that N-tuple (step 180).
Typically, the required further handling of step 170 can be implemented in one of two ways. In the first implementation, if comparison of one of the N symbols indicates an escape code, the user (i.e., the CPU, processor, controller, firmware, software, and the like, or combinations thereof, etc.) will read more bits in order to fully resolve the escape symbol. This implementation requires intervention by the user and leads to poor computing performance. The second implementation hard-codes the escape handling logic for a specific standard and if the decoder detects an escape code, it will read more bits to resolve the escape symbol using the pre-defined logic. This implementation has limited usage since the logic is fixed for one specific standard. These typical implementations are further inefficient because the decoder must individually resolve each of the N-symbols before it can determine if the N-tuple is indicative of an escape condition. Typically, the escape codes are themselves rare. However, the comparison must be made on a symbol-by-symbol basis even for all of the non-escape symbols.
Therefore, what are needed are methods and systems for the efficient detection and handling of escape codes for a variety of standards during the decoding of N-tuple variable length codes.